Should this be part of the CCTP bridge strategy?

Yes, for this use case we are already exporting CCTP_FILL_TIME_ESTIMATES from the strategy. Maybe we can use that combined with a threshold.

fast CCTP chains can be taken from here. Chains with "seconds" are considered fast

when utilization is high CCTP strategy should be used only for USDC, right?

I think we won't ever reach this line unless we're bridging USDC to USDC. See line 65 for the early exit clause.

I see we have some utils in api/_logger.ts. Can we use getLogger from there?

So I checked and that's also using the same one: https://github.com/across-protocol/frontend/blob/master/api/_logger.ts#L8

In this file, I'm only using the type Logger, not the actual logger instance.

for all these checks, should we check if the strategy we want to return is part of the supportedBridgeStrategies list? That way we avoid returning here a strategy that was previously filtered out.

Refactored it a bit to achieve this. It will help us when we add the OFT strategy as well.

I think only the origin chain matters here.

I think utilizedReserves can be negative, would that have any impact in this calculation?
I see in other places we floored it to zero when that happens. See for example: https://github.com/across-protocol/frontend/blob/master/api/_utils.ts#L2709

Nice catch!

We could instead return the expected JSON object but all fields set to false?
This would be a more clear return type than undefined.

Yeah good point, that's how I initially had it but decided to give a nullable return type instead because:

• We can only return all the fields populated in the JSON or none
• It's easier to check if we successfully fetched bridge strategy data or not. Example in these lines: https://github.com/across-protocol/frontend/pull/1864/files#diff-4c71009b75dec65194d6c79bf20fbd7122b0acfc372a2c946e8ac64de2cea414R59-R61

I think it makes sense to keep each field nullable like you said if we decide to support partial fetching of bridge strategy data, where none, some, or all of the fields can nullable. Let me know what you think though.

Can we show this behaviour in the JS doc string of the function? As a user of this function it is not immediately clear what undefined means here. Undefined can mean anything if the function does not explicitly state its meaning. And then we have to be careful, that the function can never return undefined at any other point of the function as it now has a distinct meaning.

I'll leave the decision up to you. Usually, I would argue it makes sense to make things either intuitive/the code is documentation enough or specify the behaviour as stringently as possible to avoid ambiguity.

Yeah I can add some docs. My reasoning is that each of the fields individually should never be undefined. We either have the bridge strategy data or we don't - undefined just means that we don't.

If we make all the fields in the type nullable, the structure technically feels wrong. Another option is to take the undefined out of the type and keep it in the function return type.

Maybe we want to consider extracted hardcoded variables into a single place. This would help us later to make changes or understand why certain thresholds were set.

Makes sense, will amend.